import { MdxTemplate, Answer, Question } from 'src/components/mdx';
import { LINKS } from '../../constants/links';
import MdxLayout from '../../app/MdxLayout';

<MdxLayout>
  <MdxTemplate
    pubdate={'2023-12-13'}
    ogCanonicalUrl={LINKS.articles.decompositionOfComponentsInUi.link}
    title={'Декомпозиция компонентов в UI'}
    description='Сегодня мой ученик задал вот такой хороший вопрос: "Может кто-нибудь сталкивался с такой ситуацией в командной разработке.

              Один фронт создал компонент.
              Второму фронту понадобился этот же компонент, но ему нужно изменить логику его работы, но если он её изменит, то у функционал первого фронта
              сломается?

              Что в таком случае делать второму фронту?

              Пытаться сделать компонент более переиспользуемым увеличивая количество логики внутри или создавать копию этого компонента с другой логикой?"'
  >
    Сегодня мой ученик задал вот такой хороший вопрос:

    <Question>
      Может кто-нибудь сталкивался с такой ситуацией в командной разработке.

      Один фронт создал компонент.
      Второму фронту понадобился этот же компонент, но ему нужно изменить логику его работы, но если он её изменит, то у функционал первого фронта
      сломается?

      Что в таком случае делать второму фронту?

      Пытаться сделать компонент более переиспользуемым увеличивая количество логики внутри или создавать копию этого компонента с другой логикой?
    </Question>

    Командными усилиями учеников мы пришли к двум вариантов ответов:

    <Answer title={'Длинный ответ'}>
      Есть несколько подходов, которые можно рассмотреть:

      1. Переиспользование с параметрами или настройками:
      Попробуйте сделать компонент более гибким и параметризуемым. Разработайте его таким образом, чтобы части логики можно было настраивать снаружи
      компонента, например, через передачу параметров или использование свойств.

      2. Создание расширенной версии:
      Если новая логика сильно отличается от оригинала и может привести к различному поведению, может быть разумным создать новую версию компонента.
      Основная идея останется, но внутренняя реализация будет подстроена под новые требования.

      3. Изоляция изменений:
      Иногда возможно выделить часть компонента, которая будет отвечать только за изменяемую логику. Это позволит вам создать расширение или
      модификацию
      компонента без влияния на основной функционал.

      4. Разделение на отдельные компоненты:
      Если изменения слишком существенны и концептуально отличаются, может быть лучше создать два отдельных компонента с разной логикой. Это поможет
      избежать путаницы и сохранит чистоту и понятность кода.

      Выбор подхода зависит от конкретной ситуации, уровня изменений и архитектурных требований проекта. Важно также учитывать возможные последствия
      для
      существующего функционала и тестируйте изменения, чтобы убедиться, что они не ломают работу других частей системы." как то так )
    </Answer>

    <Answer title={'Короткий ответ'} className='mt-3'>
      У вас ранее был компонент А, и вам нужно получить в результате работы компоненты А1 Б В, где:

      - А1 - компонент отвечающий за общую или базовую логику
      - Б - А1 + описание логики присущее А
      - В - А1 + описание новой бизнес логики

      Обычно А1 описывают в максимально простом виде
    </Answer>
  </MdxTemplate>
</MdxLayout>
